FIG. 1 illustrates a system 100 showing a typical operation between an application 102 and a device 104, such as a disk drive. A device 104 is connected to a computer 106 via a connection 108, such as a SCSI cable which is coupled to a card called a Host Bus Adapter (HBA) 110. The HBA 110 is coupled to the computer 106.
The computer 106 comprises a number of layers, including an application layer and an operating system layer. The application layer comprises the application 102 to communicate with the device 104. The operating system layer comprises a target driver (not shown) and an HBA Driver 112. The target driver communicates with a device 104 by using the services of the HBA driver 112 to allow applications 102 access to a particular device, such as a disk drive, for example. The HBA Driver 112 communicates with an HBA card 110.
Thus, applications 102 send requests for disk I/O to a target driver, and the target driver converts those to commands that an HBA 110 can execute and passes them down to the HBA driver 112. The HBA driver 112 passes the requests on to the HBA card 110. The HBA card 110 passes them down the SCSI bus cable 108, and the target device 104 (e.g., a disk) receives and operates on them.
An application 102 communicates with a device 104 through an HBA driver 112. For example, if an application 102 wants to communicate with a device 104 that is a disk drive, the application 102 sends the request to the HBA Driver 112, which, in turn, passes an IOCB 120 (Input/Output Control Block) to the device 104 via the HBA 110. An IOCB 120 comprises fields of information about the request, such as whether the request is a read or write, where to read from on the disk drive if the request is a read, a pointer to data if the request is a write, and which disk drive to read from or write to.
When the HBA Driver 112 passes an IOCB 120 to the HBA 110, it also saves request data in a driver memory 114 so that the HBA Driver 112 can track the status of requests that are sent to the HBA 110. The IOCB 120 is placed on a request queue 116 on the computer 106 until the HBA 110 is ready to process the IOCB 120.
The IOCB 120 is then processed by the HBA 110, and the request satisfied (if at all) by the device 104. When the IOCB 120 completes, or has a problem, a response, or a corresponding IOPB 122 (Input/Output Parameter Block), which comprises information similar to the IOCB 120, is put on a response queue 118 until the HBA Driver 112 is ready to process the IOPB 122. The HBA Driver 112 must then match the IOPB 122 to the appropriate IOCB 120 so that the request (IOCB 120) is matched with the correct status (IOPB 122), and the address in the driver memory 114 in which the request data was saved can be released.
In the past, reconciling the IOPB 122 to the IOCB 120 was accomplished using pointers. One of the fields in the IOCB 120 comprises a request token that identifies an area of the driver memory 114 in which data about the request is stored. The request token comprised a pointer into the array. Later, computers were developed which gave users an option to operate in dual mode: thus, given a 64-bit computer, users could operate in 64-bit mode or 32-bit mode, for example. When a faster mode (i.e., 64-bits) was chosen, however, corresponding 64-bit pointers became problematic since the HBA 110 was only engineered to process 32-bit words. While the HBA could be reengineered to process in 64-bit or 32-bit mode, it was much easier to modify the software design of the HBA Driver 112.
One solution to this was to implement a system 200, shown in FIG. 2, in which a translator 204 is used to convert a 64-bit word into a corresponding 32-bit word, and vice versa. When the 64-bit mode is chosen, 64-bit pointers allow 264 addresses in the driver memory 114 to be accessed. When a request is received by the HBA Driver 202, a 64-bit pointer is created by the HBA Driver 202 to identify the request, and data about the request is stored in a driver memory 114 address corresponding to the 64-bit pointer. However, since the pointer is 64 bits, and the HBA 110 is engineered to read 32-bit words, a conversion needs to take place before the IOCB 120 can be sent to the HBA 110.
To accommodate the larger 64-bit token, the translator 204 converts the 64-bit pointer into a 32-bit token that can be placed into the token field of the IOCB 120, so that the HBA 110 can read a 32-bit token. When the HBA 110 sends a response upon completing the request, an IOPB 122 comprising the 32-bit token is sent back to the HBA Driver 202. However, in order for the HBA Driver 202 to match the response to the correct request, the 32-bit token must be converted back to the 64-bit pointer corresponding to the driver memory 114 where the request data is stored. Thus, the translator 204 converts the 32-bit token in the IOPB 122 token field back into a 64-bit pointer into the driver memory 114, and the address is then released for subsequent requests.
While the solution works for valid addresses in the driver memory 114, the solution is not robust. If the hardware fails, and the conversion from a 2-bit token to a 64-bit token generates a wrong 64-bit token, then the wrong request is referenced, and the wrong address released. Even worse for some systems, if the conversion generates a 64-bit token that has never been used, the system may crash.